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(54) "Integrated circuit with embedded emulator and emulation system for use with such an 
integrated circuit" 



(57) A dHiH processor (20) is provided with an em- 
bedded omuUtor which can be initiated by a signal on 
a control pin (EA) or by a single byte emulation instruc- 



tion embedded within a user's programme which the us- 
er wishes to debug. The emulator is software driven and 
uses reserved emulation registers (EMUCON, 
EMU1.EMU2). 
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Description 
TECHNICAL FIELD 

[0001] The present invention relates to an integrated 
circuit liaving an emulator embedded tlierein, and to an 
emulation system tor use with such an integrated circuit. 

BACKGROUND OF THE INVENTION 

[0002] Executable code for a data processor such as 
a microcontroller, requires testing and correction during 
its development cycle. Software debugging is initially 
done in a simulator or debugger offline. Once the soft- 
ware is debugged, it is then down loaded into the target 
system. However, It the software does not work correct- 
ly, for example, due to a timing problem it is then nec- 
essary to do an "in circuit" examination ot the software 
and the data that it is manipulating. It is known to perform 
this by removing the target data processor and replacing 
it with a replica of the data processor which can be 
probed or interrogated via an emulation pod. The replica 
data processor emulates the real data processor and 
this process is called "in circuit emulation'. 
[0003] A disadvantage of known "in circuit" emulators 
is that the additional sockets, clips, adaptors or pods can 
induce extra parasitic components into the target sys- 
tem which alter its performance. This usually restricts 
the emulation to a slow speed in order to avoid timing 
problems introduced by the parasitic components. The 
use of such in circuit emulators can cause problems 
where debugging is to be performed in hybrid digital- 
analogue systems where analogue accuracy is a critical 
issue, especially when more than 6 or 7 bit resolution of 
analogue variables is used. 

[0004] It was also known, in the case of microcontrol- 
lers where the internal address and data busses do not 
come out to the pins of the data processor, to produce 
a special "bond-out" version of the circuit. This has to 
be manufactured into a bigger package to bring these 
extra signals to the pins so that the emulator can monitor 
them. The bond-out version is disadvantageous since it 
requires the chip manufacturer to create a second ver- 
sion of the chip and package, with consequent timing 
differences from the real chip, increased complexity, 
and a need to provide an adaptor for connecting the 
"bond-out" version of the chip to target systems in place 
of the standard chip package. 

[0005] It is known to integrate emulation address 
comparators and emulation break point registers within 
an integrated circuit and then to perform a hardware 
compare of the contents of the address register with the 
emulation break point register in order to determine 
when to force a break point for emulation purposes. 
However, the additional registers and comparators are 
wasteful of space on the silicon die of the integrated cir- 
cuit, and are inflexible in their operation. An additional 
register and comparator is required for each break point. 



Typically a designer may wish to have between eight 
and sixteen break points available. The addition of six- 
teen or so additional registers and comparators can add 
a significant cost to the production cost of the integrated 
5 circuit. 

SUMMARY OF THE INVENTION 

[0006] According to a first aspect of the present inven- 
tion, there is provided a data processor including an em- 
ulation controller for causing the data processor to enter 
an emulation mode, and dedicated registers for use in 
the emulation mode. 

[0007] It is thus possible to provide a software driven 
emulator within a data processor which leaves the reg- 
isters used by the data processor to execute tasks un- 
altered during an emulation or debug operation. A soft- 
ware driven emulator is flexible and allows, for practical 
purposes, for an unlimited number of break points to be 
implemented. 

[0008] Preferably the registers dedicated for use by a 
data processing core (also known as an arithmetic logic 
unit) of the data processor during emulation can only be 
altered during emulation. 

[0009] Advantageously a programme for controlling 
the operation of the data processing core during emu- 
lation is stored in a reserved non -volatile memory area 
which is hidden from the user of the data processor. 
[0010] Preferably the emulation controller can oper- 
ate in a single step mode wherein the register status of 
the data processor, or other information such as the con- 
tents of a stack or memory can be output after executing 
a single instruction of the user's programme. Addition- 
ally or alternatively, the emulation controller is respon- 
sive to a single byte instruction placed in the user code 
in order to initiate the emulation mode. The single byte 
instruction is, in general written over another instruction 
in the user's programme. In order to ensure that the us- 
er's program performs as intended, the overwritten in- 
struction is held in a special purpose register so that it 
is executed when the emulation mode is exited. Addi- 
tionally or alternatively, the data processor may also be 
responsive to a signal on one of the data processor con- 
trol pins in order to initiate the emulation mode. 
[0011] According to a second aspect ot the present 
invention, there is provided a data processor having an 
emulator embedded therein, and in which the emulator 
is initialed by a single word instruction. 
[0012] According to a further aspect of the present in- 
vention, there is provided a data processor including an 
emulator therein arranged to communicate information 
concerning the internal status of the data processor via 
a serial communication link. 

[0013] Preferably the serial data link utilises a pin in 
the data processor package. Advantageously the pin is 
multiplexed with a control function of the data processor. 
For example, some data processors include control pins 
which are only relevant during the power up initialisation 
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ot the data processor. The pin may indicate to the proc- 
essor whether it is to initially execute instructions from 
an internal or an external memory. Once this Information 
has been conveyed to the processing core of the data 
processor the pin becomes effectively redundant. Such 
a pin may then be used as a communication link be- 
tween the embedded emulation system within the data 
processor and an external development system or em- 
ulator controller. 

[001 4] Preferably the emulator is responsive to a sig- 
nal on the pin, such as a voltage transition, in order to 
activate the emulator. 

[0015] Preferably the emulator is a software control- 
led emulator, and comprises emulation instructions held 
as software within a reserved memory integrated into 
the data processor. The receipt of the instruction to start 
emulation, either by a signal on the emulator control pin 
or via a software instruction within the software being 
debugged, forces the data processing core of the data 
processor to suspend execution of the user's program- 
ming code and to execute instructions from the emula- 
tion instruction code. Preferably the receipt of an instruc- 
tion to commence emulation causes a high level non 
maskable interrupt to be issued to the data processing 
core of the data processor. 

[0016] Preferably the data processor executes emu- 
lation instructions using reserved emulation registers, 
thereby leaving the contents of the registers used for 
programme code execution unaltered, except possibly 
for the programme address controller and the stack 
which may experience some minor and wholly reversi- 
ble alterations. Advantageously an auxiliary stack and/ 
or auxiliary programme address counters may also be 
provided solely for use within the emulation routine such 
that the registers, programme counter and stack used 
by user executable code may be left entirely unaltered. 
As an alternative dedicated registers may also be pro- 
vided for storing the contents of the program address 
controller. In yet a further alternative, the data processor 
may be arranged to down load the stack and register 
contents to virtual registers with an emulator control da- 
ta processor or within an interface element, and to up 
load the register and stack contents when exiting the 
emulation mode. 

[001 7] According to a further aspect of the present in- 
vention, there is provided a development system com- 
prising a control data processor for monitoring the status 
of a target data processor, wherein the target data proc- 
essor includes an embedded emulator for communicat- 
ing information concerning the internal status of the tar- 
get data processor via a serial communications link, the 
development system including interface element adapt- 
ed to communicate via the serial communications link. 
[0018] The interface element may be in the form of a 
pod providing electrical isolation between the target and 
control data processor. Advantageously the pod pro- 
vides bi-directional communication between the target 
and control data processors and includes a controllable 



voltage generator for causing a voltage transient on an 
emulation control pin of the target data processor for 
forcing it to enter the emulation mode. The voltage gen- 
erator may also be used to communicate data and in- 
5 structions to the target data processor 

[0019] Advantageously the interface element com- 
municates with the control data processor via a conduc- 
tive link, such as a cable. Alternatively, the communica- 
tions pod may communicate with the control data proc- 
10 essor over a radio or optical based, such as infra-red, 
communications link. Advantageously the or each com- 
munications pod has a unique identity such that a plu- 
rality of pods may be independently addressed by a sin- 
gle emulation control data processor Thus the emula- 
'5 tion control data processor can control and/or debug a 
plurality of target data processors within a target system. 
[0020] Advantageously the or each interface element 
contains a local data processor for handling any timing 
features or handshaking required to communicate over 
20 the data link. The local data processor may contain reg- 
isters or memory for temporarily storing the register con- 
tents of an associated target data processor, or may 
handle the modification of a block user program code, 
ie changing the code or inserting a break point instruc- 
ts tion. 

[0021] In a preferred embodiment, the or each inter- 
face element is a pod having three pins, one for connec- 
tion to ground, one for connection to the power rail Vcc, 
and one for connection to the pin on the target data proc- 
30 essor for communication therewith. 

[0022] It is thus possible to integrate emulation and 
debug features with a data processor, thereby ensuring 
that emulation has minimal effect on the operation of the 
target board. 

35 [0023] The present invention will further be described, 
by way of example, with reference to the accompanying 
drawings, in which; 

Figure 1 schematically illustrates a prior art emula- 
te tor arrangement; 

Figure 2 schematically illustrates an emulator con- 
stituting an embodiment of the present invention; 

45 Figures 3a and 3b schematically illustrate the mem- 
ory organisation within a data processor constitut- 
ing an embodiment of the present invention in nor- 
mal operation and in emulation mode, respectively; 

so Figure 4 schennatically illustrates the internal layout 
of a microcontroller constituting an embodiment of 
the present invention; 

Figure 5 schematically illustrates the internal layout 
55 of a microcontroller constituting a further embodi- 
ment of the present invention; 

Figure 6a to6d schematically an emulation in a sin- 
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gle step mode; 

Figure 7 schematically illustrates an emulation us- 
ing a single step break point instruction; 

Figure 8 shows a layout of a special purpose emu- 
lation register; and 

Figure 9 schematically illustrates the emulation sys- 
tem. 

DESCRIPTION OF PREFERRED EMBODIMENTS 

[0024] Figure 1 schematically illustrates a prior art 
emulator in which a large emulation pod plugs into the 
data processor socket on a customer's target board in 
order to provide interconnection with an emulator sys- 
tem comprising an emulation control processor running 
an omuiHtcr soliware package which typically displays 
register conicnls ol the target processor and allows for 
editing oJ triMiuclions via a graphical user interface 
(GUI I The Irirgc si/c Of the emulation pod nnakes it in- 
convenient lo use and also can give rise to subtle chang- 
es in opcfciion of the target board due to the extra load 
and p.iraGilic components introduced by the emulation 
pod Furihormoro the known emulation pod uses a dif- 
ferent or modittod data processor which gives rise to 
changes m output driver characteristics and loadings 
which can ofloci signal timings and degrade analogue 
perfornrwnce where analogue circuits or DAC or ADC's 
are involved 

[0025] As shown in Figure 2, an emulation system 
comprising a data processor constituting an embodi- 
ment of the present invention and an interface card 3 for 
providing galvanic isolation between the customer's tar- 
get board and the emulation control data processor 2 
provides for a more compact emulation system and, 
more importantly does not change the operating char- 
acteristics ot the customer's target board due to the in- 
troduction ol parasitic components. 
[0026] The data processor having an emulator ac- 
cording to the present invention performs emulation un- 
der software control. In order to achieve this a reserved 
memory containing emulation instructions is provided 
as an integral pan of the data processor. As shown in 
Figure 3a, a data processor may have, for example, a 
memory space in which addresses OOOOH to 1FFFH 
(where "H" indicates that the addresses are expressed 
in hexadecimal) are provided for internal user pro- 
gramme code and the addresses 2000H to FFFFH are 
allocated to external user code space. The emulation 
memory is placed on another page of memory such that 
it remains hidden from the user. Thus, for example, ex- 
ternal memory addresses F900H to FFFFH may contain 
a user programme, whereas internal addresses F900H 
and above contain the emulation programme. 
[0027] Figure 4 schematically illustrates the internal 
arrangement of a data processor, generally illustrated 



as 20, whereby a programme address controller 22 
holds the address of the next memory location to be read 
from. This location normally points to a boot strap mem- 
ory 24 which contains executable code to be used dur- 

5 ing power up sequences or for data exchange routines, 
or to a user programme 26 which may be stored in an 
internal user code memory 28 or in external memory 
(not shown). The programme address controller 22 is 
responsive to an interrupt request handler 30 which, as 

10 is well known in the art, allows normal execution of a 
programme to be interrupted in order to respond in a 
predetermined way to specific events. The data proces- 
sor is arranged to execute an interrupt routine in re- 
sponse to an interrupt request and then to return to the 

J5 user code when the interrupt routine has been complet- 
ed. The data processor constituting an embodiment of 
the present invention is also provided with an emulation 
request controller 32 which issues a priority non- mask- 
able interrupt request which takes precedence over all 

20 other interrupt functions. The interrupt controller 30 is 
arranged to buffer incoming interrupts while the pro- 
gramme address controller is responsive to the emula- 
tion request controller 32 in order to ensure that interrupt 
requests are properly serviced upon return from the em- 

25 ulation mode. 

[0028] The emulation request controller is responsive 
to three inputs. A first input is responsive to a voltage 
transition on a single pin of the data processor package. 
In the preferred embodiment, the pin is a "E A" pin which 

30 is used to tell the data processor and it should execute 
from internal (EA = high) or external (EA = low) memory 
during the power up. The state of the pin is latched by 
the data processor at power up or reset and thereafter 
it can be used as the emulation control pin. The EA pin 

35 is also used, when emulation has been initiated, as a bi- 
directional serial communications pin. 
[0029] The emulation request controller is also re- 
sponsive to a single step flag 42 which ensures that an 
emulation request occurs after execution of a single in- 

40 struction of the user programme code. Preferably, the 
emulation controller 32 is responsive to a break point 
instruction whose occurrence in the user code causes 
the emulation controller 32 to issue an emulation re- 
quest. 

45 [0030] As shown in Figure 5, a break point instruction 
decoder 50 is provided to specifically handle the occur- 
rence of the additional single byte emulation instruction 
(break point instruction) contained within user pro- 
gramme memory 52, which may be external memory or, 

so more likely, internal memory area 28. Additionally, a 
special register EMU2 is provided to hold the instruction 
which was overwritten by the emulation request instruc- 
tion thereby ensuring that the addresses of the remain- 
ing programme code are unaltered. As shown in Figure 

55 5, the data processing core 54 (also known as an arith- 
metic logic unit ALU) has a dedicated set of reserved 
registers 56. EMUCON. EI^U1 and EMU2, for use dur- 
ing emulation. The reserved register set may also in- 
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elude an alternative stack and/or programme counter for 
use during emulation. 

[0031] Figure 8 illustrates the emulation control reg- 
ister, EMUCON, provided within a data processor in- 
cluding an embedded software controlled emulator. 
Working from the left to right, the first three bits of the 
register form a control word which causes internal timers 
and clocks of the data processor to be disabled if the 
correct code, in this example 101, is written into these 
bits of this special function register. Th is enables the em- 
ulator to halt internal timers and interrupts when execut- 
ing an emulation function. The fourth bit is an emulation 
enable bit, EE, which is placed in the enable condition 
by default and enables emulation to be started when an 
appropriate emulation request is received by the emu- 
lation request controller The fifth bit enables execution 
of the contents of the special function register EMU2. 
When an emulation routine is started by the occurrence 
of the emulation break point in the user programme 
code, this EES register is inspected in order to deter- 
mine whether the breakpoint instruction should actually 
be executed. If the contents of this register are not set, 
then the emulation will be performed. When the emula- 
tion routine is completed, the address pointer points to 
the address ot the break point. As mentioned earlier the 
original instruction which was overwritten by the break 
point is loaded into the EMU2 special function register 
and the bit EES is cleared. As the emulation programme 
returns control to user code, it sets the EES bit. The ad- 
dress programme counter will return control at the ad- 
dress of the break point instruction. However, this time 
the EES bit is set and instead of re-executing the emu- 
lation routine, the processing core of the data processor 
is caused to execute the instruction held in the EMU2 
special function register The EES bit is then toggled 
once the instruction in the EMU2 register is executed, 
thereby ensuring that the next occurrence of the break 
point instruction will cause the emulation routine to be 
re-entered. 

[0032] The sixth bit is an emulation single step, ESS 
bit which causes the data processor to on ly execute sin- 
gle instructions between emulator programme opera- 
tions. 

[0033] The final two bits EA-in and EA-out enable the 
status of the EA pin to be read and written to respective- 
ly 

[0034] Figures 6a to 6d schematically illustrate oper- 
ation of the emulator in a single step code execution 
mode. The emulation routine takes advantage of the fact 
that the emulation interrupt will not respond until at least 
one instruction of the user code has been executed. 
Thus once control has been passed from the emulator 
to the user code, the emulator issues, via a hardware 
resource, a highest priority non-maskable interrupt that 
ensures that programme execution is immediately re- 
turned to the emulator, irrespective of what instruction 
was being performed. 

[0035] Thus as shown in Figure 6a, the emulation 



control data processor is arranged to issue an emulation 
request via the EA pin which causes a jump to the em- 
ulation memory. This initially allows communication be- 
tween the emulation control data processor 2 and the 

5 emulator in order that new instructions can be set in the 
emulator, such as changing one or nnore ot the flags in 
the EMUCON register, in this example, the control data 
processor sets the single step instruction, ESS, flag In 
the EMUCON register. Once the emulation control data 

10 processor has indicated that it does not wish to set any 
further instruction changes, control is relinquished from 
the emulation code and the user code is executed. How- 
ever, since the EMUCON register was set with the single 
step enabled, and interrupt request is issued via the em- 

15 ulation controller 32 thereby causing control to be re- 
turned to the emulation code after a single instruction of 
the user code has been executed as shown in Figure 
6c. The emulation code then down loads data to the em- 
ulation control data processor 2 via the EA pin. Down 

20 loaded data may include the status of the intemal reg- 
isters of the data processor, but may also, depending 
on instructions received from the emulation control data 
processor, include the contents of the stack and also the 
contents of selected areas of internal or external mem- 

25 ory, or the contents of an internal cache. 

[0036] Figure 7 illustrates an example of an emulation 
request initiated via the break point instruction. 
[0037] The data processor has a data processing core 
supporting the 8051 instruction set. The 8051 instruction 

30 set has a unused instruction code of A5. The AS instruc- 
tion has been implemented as the break point instruc- 
tion. 

[0038] It is known to initiate a software emulation or 
debug by including a jump instruction to the emulation 

35 code. However there is a significant problem with this 
approach since the jump instruction is a 3 byte instruc- 
tion and if this was inserted at address 0120, as shown 
in Figure 7 then the inc A and DAA instructions at ad- 
dresses 01 21 and 01 22, respectively, would be overwrit- 

40 ten by the jump instruction. Thus it would be necessary 
to change the addresses of the subsequent steps in or- 
der to incorporate the addition of this jump driven emu- 
lation instruction. Secondly, in order to use this ap- 
proach, the emulation memory/programme must be vis- 

45 ibie for the jump to work and consequently the incorpo- 
ration of the emulation code within the data processor 
would limit the user's programming options. A third prob- 
lem is that, if the addresses of all the remaining code 
was not changed, it would result in the instructions at 

50 0121 and 01 22 being lost, and also an additional break 
point could not be inserted at the overwritten addresses. 
[0039] By adding a single byte break point instruction, 
only one address of programme is over written. Thus in 
the example in Figure .7 only the "clear A" instruction at 

55 01 20 is ovenwritten by the inclusion of the software driv- 
en emulation breakpoint instruction. However, the clear 
A instruction is written into the EMU2 register in order 
to ensure that it is executed as if the break point instruc- 
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tion were not there. If a break point instruction is to be 
written into the user code for debugging/development 
purposes, the emulator- reads out a block of nnemory 
containing the program code containing the address of 
the instruction to be changed, An internal memory con- 
troller then erases the block of memory, and in co-oper- 
ation with the emulation control data processor, re-pro- 
grams the block of memory adding the break point in- 
struction. The precise memory control strategies for per- 
forming the modification of internal memory within the 
data processor, ie within a single chip package, are not 
critical to the present invention, but a suitable memory 
and memory controller is described within a co-pending 
application filed by Analog Devices, and titled "A MEM- 
ORY AND A DATA PROCESSOR INCLUDING A MEM- 
ORY". The interface element 3 may provide a local buff- 
er such that as the block of program code (usually two 
rows on the internal non-volatile reprogrammable user 
code memory of the data processor), is buffered in the 
interface element and the local data processor modifies 
the data to change instructions or insert the break point, 
and then represents the data to the target data proces- 
sor In order that it can rewrite the data into it's intemal 
memory. 

[0040] During execution of the user programme, the 
programme counter will eventually point to the address 
01 20 which has the A5 emulation break point instruction 
written therein in place of the "clear A" instruction. The 
instruction decoder of the data processor decodes the 
break point instruction and causes the emulation re- 
quest controller 32 to issue a priority interrupt. Thus the 
data processing core 54 discontinues execution of the 
user's programme and starts executing instructions 
from the emulation memory provided that the EES bit in 
the EMUCON register cleared. Assuming that the EES 
bit is cleared, the data processing core executes the em- 
ulation instructions using the reserved EMU1 register, 
and outputs data concerning the status of the various 
programme registers tothe emulation data processor 2. 
Once the data has been sent to the emulation data proc- 
essor, the emulation data processor toggles the EES bit 
and issues a command causing the emulation to contin- 
ue. The emulator then returns control to the user pro- 
gramme. Because the break point instruction is interrupt 
driven, the control is returned to address 0120 which 
holds the A5 break point instruction. This time the EES 
bit indicates that emulation should not be recom- 
menced, but in fact that the instruction in the EMU2 reg- 
ister should be executed. The data processing core ex- 
ecutes the instruction in the EMU2 register and returns 
control to the user programme at the address following 
the break point instruction. 

[0041] Figure 9 schematically illustrates a multi-target 
development system in which a single control data proc- 
essor 2 communicates with a plurality of target data 
processors via a plurality of interface elements 3, each 
of which contain a local data processor 100 which re- 
duces the computational load on the control data proc- 



essor by performing the communications protocols and 
also buffers and modified data in the target data proc- 
essors in response to commands from the emulation 
control data processor 2. 

5 [0042] It is thus possible to provide a data processor 
having a software driven emulator embedded therein 
which uses dedicated registers, thereby ensuring that 
registers used in execution of a user's programme do 
not become altered once the emulation mode is com- 

10 menced. It is also possible to provide a development 
system for use with such a microprocessor in order that 
the intemal registers may be inspected, or blocks of 
memory may be inspected and analysis performed ther- 
eon. For example, a block of memory may hold values 

15 resulting from analogue to digital conversions. The val- 
ues may be displayed by the emulation control data 
processor in order to form an oscilloscope trace of the 
analogue value, or additionally or alternatively may be 
Fourier transformed in order to perform frequency do- 

20 main analysis. The emulator may be used to perform a 
software controlled series of Analogue to Digital conver- 
sions, and to send these to the emulator control proc- 
essor which can then display a graph or trace of the con- 
verted variable. The emulator 2 may display a plurality 

25 of windows, with each displaying the status of and/or 
controlling the function of a respective target data proc- 
essor within a multi-processor target board. Thus the 
operation of master and slave processors may be ana- 
lysed, possibly on a single step basis, in order to check 

30 their data exchange operations and mutual perform- 
ance. 

[0043] The emulator has authority to modify the inter- 
nal memory contents of program and data memory with- 
in the target data processor. Thus the target data proc- 

35 essor may be re-programmed whilst it is in situ in the 
target board. Similarly calibration coefficients in digital 
or hybrid digital-analogue systems can be modified. It is 
also possible, when the interface element communi- 
cates using a radiative link, to leave the interface ele- 

40 ment attached to the target board permanently, thereby 
allowing for the target data processor to be re-pro- 
grammed even after it has been installed in a working 
environment. The provision of an emulator as an integral 
part of the target data processor has the additional ad- 

45 vantage that the board and processor being debugged/ 
developed are identical to the final system. This con- 
trasts with prior art emulators of the type shown in Figure 
1 whereby the data processor on the emulation pod syn- 
thesises the functions of the target data processor but 

50 In often a physically different type of processor which 
may have additional hardware attached thereto to sim- 
ulate the ports of the target data processor. 

55 Claims 

1. A data processor characterised by an emulation 
controller (32) for causing the data processor (20) 
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to enter an emulation mode, and dedicated regis- 
ters (EMUCON.EMUl ,EMU2) for use in the emula- 
tion mode. 

2. A data processor as claimed in Claim 1 . 
characterised in that the dedicated registers (EMU- 
CON.EMU1,EMU2) can only be altered when the 
data processor (20) is in the emulation mode. 

3. A data processor as claimed in Claim 1 or 2, 
characterised by further comprising a non-volatile 
emulation memory (24) for storing instructions to be 
performed by a data processing core (54) of the da- 
ta processor (20), and in which the emulation con- 
troller (32) causes the data processing core (54) to 
execute instructions from the emulation memory 
(24). 

4. A data processor as claimed in any one of the pre- 
ceding Claims, characterised in that the emulation 
controller (32) is responsive to a signal on an emu- 
lator control terminal (EA) to initiate the emulation 
mode. 

5. A data processor as claimed in Claim 4, 
characterised in that the signal is a voltage transi- 
tion. 

6. A data processor as claimed in Claim 4 or 5, 
characterised in that the control terminal is a pin 
(EA) of the data processor which is used to control 
other functions of the data processor during a pre- 
determined operation thereof. 

7. A data processor as claimed in Claim 6, 
characterised in that the predetermined operation 
is an initialisation sequence. 

8. A data processor as claimed in any one of the pre- 
ceding Claims, characterised in that the emulation 
controller (32) is responsive to a control signal held 
in a storage element. 

9. A data processor as claimed in Claim 8, 
characterised in that said control signal (ESS) is a 
single step control signal which causes the data 
processor (20) to only execute a single instruction 
of a user's programme before returning to the em- 
ulation mode. 

10. A data processor as claimed in Claim 8 or 9, 
characterised in that said control signal is stored as 
a single bit within a register (EMUCON). 

11. A data processor as claimed in Claim 10, 
characterised in that said register (EMUCON) is an 
emulation control register for storing signals for con- 
trolling the functions executed in the emulation 



mode. 

12. A data processor as claimed in any one of the pre- 
ceding Claims, characterised in that said emulation 

5 controller (32) is responsive to an emulation instruc- 
tion inserted into the user's program for causing the 
data processor to enter the emulation mode. 

13. A data processor as claimed in Claim 12, 

10 characterised in that said emulation instruction is a 
single word instruction, 

14. A data processor as claimed in Claim 13, 
characterised in that said emulation instruction is a 

15 single byte instruction. 

15. A data processor as claimed in any one of Claims 
1210 14, characterised in that the emulation instruc- 
tion causes a jump to be performed from the user's 

20 programme to the emulation programme. 

16. A data processor as claimed in any one of Claims 
1 2 to 1 4, characterised in that the emulation instruc- 
tion causes an interrupt to be issued to the data 

2S processing core (54). 

17. A data processor as claimed in any one of Claims 
1 to 14, characterised in that the emulation control- 
ler (32) issues a priority non-maskable interrupt to 

30 a data processing core (54) of the data processor 
(20) in order to initiate the emulation mode. 

18. A data processor as claimed in any one of the pre- 
ceding claims, characterised in that the data proc- 

35 essor includes an emulation control register (EMU- 
CON) containing bits for controlling at least one 
function selected from a list comprising: halting of 
counter and timers internal to the data processor; 
single step operation; enabling the interrupt mode 

40 to be initiated by an emulation instruction within the 
user's code; and executing an Instruction held in an 
instruction register, said instruction corresponding 
to the instruction that was ovenwritten by the inser- 
tion of the emulation instruction into the user's pro- 

45 gramme. 

19. A data processor as claimed in any one of the pre- 
ceding claims, characterised in that the registers 
used during execution of user's programme instruc- 

50 tions are left unaltered during emulation mode. 

20. A data processor as claimed in any one of the pre- 
ceding claims, characterised in that the contents of 
registers used during execution of a user's pro- 

55 gramme are read and output via a data link during 
emulation mode. 

21. A data processor as claimed in Claim 20, 
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characterised in that the contents of at least one of 
the stack and the progrannme counter of the data 
processor are read and output via the data link. 

22. A data processor as claimed in claimed in Claim 1 7. 5 
characterised in that the contents of the programme 
counter are pushed onto the stack at the com- 
mencement of the emulation mode. 

23. A data processor as claimed in Claim 17. io 
characterised in that an emulation stack and an em- 
ulation programme counter are provided for use by 
the data processing core (54) during the emulation 
mode. 

75 

24. A data processor as claimed in any one of the pre- 
ceding claims, characterised in that data from the 
emulator is output as a serial data stream. 

25. A data processor as claimed in any one of the pre- 20 
ceding claims, characterised in that the emulator is 
responsive to an external emulator control device 
(2,3) to output information upon command, said in- 
formation comprising at least one item from a list 
comprising: the contents of at least one register of 25 
the data processor; the contents of a stack of the 
data processor; the contents of a programme coun- 
ter of the data processor; the contents of a selected 
memory address; and the contents of a selected 
block of memory addresses. 30 

26. A data processor (20) having an emulation function 
embedded therein, characterised in that the emula- 
tion function is initiated by a single word instruction. 

35 



45 



so 



55 
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